Various admission control mechanisms (e.g., call admission control, CAC) may be used within a computer network to control the amount of traffic traversing network elements (links/nodes). For example, service providers may limit the number of end-to-end data flows (e.g., Voice over Internet Protocol, VoIP calls) in order to prevent over-burdening the network, potentially leading to network congestion. Generally, admission control may occur at the edges of a service provider's network (e.g., edge-to-edge admission control in a core network) based on the status of the nodes within the network, and may either admit or deny a data flow use of the network, sometimes along a particular selected (admitted) path. Changes in the network, however, such as due to failures, re-routes, etc., may allow data flows to bypass admission control, since the flows are no longer on their originally admitted paths. Also, “flash crowds” (where many new flows are created at substantially the same time) may overburden the network resources, such that admission control may not be able to effectively manage the number of new flows. Because of these reasons, some links and nodes within the network may become congested. (Notably, congestion, as used herein, implies that a link or node in the network is receiving more traffic than a configurable threshold up to a maximum amount of traffic the link or node can handle.)
Generally, all flows sharing a congested network element become affected and suffer potentially substantial Quality of Service (QoS) degradation due to conventional per-packet control, such as dropping individual packets (from all flows) in order to relieve congestion. If the flows are voice flows, then potentially all users may “hang up” if the QoS degradation lasts longer than a few seconds. It is often desirable, therefore, to selectively “preempt” (drop/deny admission for) certain flows to alleviate congestion, and restore the necessary level of QoS for the non-preempted flows. For example, low precedence calls may be preempted to allow higher precedence calls to remain; however the precedence level of calls is not always available (e.g., due to security/encapsulation, etc.), thus limiting the use of such selective preemption. Some flow control networks, therefore, perform per-packet processing within the network to determine whether congestion exists, and mark packets that are received at a rate faster than the receiving node can forward over the desired path (or, notably, greater than a “preemption threshold” to prevent reaching the maximum physical rate). Information/feedback about the number of marked packets may be used (e.g., by an ingress node originating the data flows into the core network) to determine how many/which flows to preempt based on the network conditions.
One example solution that attempts to alleviate the occurrence of congestion within the network is described with a Resource Management in DiffServ (RMD) concept in an Internet Draft by Bader, et al., entitled RMD-QOSM—The Resource Management in DiffServ QOS Model<draft-ietf-nsis-rmd-07.txt>, dated June 2006, which is hereby incorporated by reference in its entirety. As described therein, the rate at which flows enter an output queue of a network node is measured such that a degree of overload may be computed. Packets may then be marked so that a number of marked packets leaving the output of the node is proportional to the degree of overload computed. For example, assuming a 10% overload is observed, then 10% of the previously unmarked traffic is marked at the output of the queue. The egress node of the network computes an overall degree of overload and informs the ingress node, which may then preempt any necessary traffic flows.
Yet, there are circumstances where the above solutions may preempt too many flows based on the feedback received. For instance, when there are multiple network elements that are congested within a network, packets from flows may be marked at multiple locations. In this manner, when feedback is returned to the flow control node (e.g., ingress node), the markings reflect congestion that may be worse than what actually exists in the network, and the flow control node may consequently preempt more flows than necessary to alleviate the actual congestion (i.e., the flows have been “beat-down”). For rate-adaptive flows, the beat-down problem is reduced since aggressively reduced (beat-down) rates may be dynamically increased as part of normal rate adaptation. However, in the context of preemption (dropping/denying entire flows), once a flow is preempted, it is no longer operational within the network, and may not return. It is therefore undesirable to beat down flows in a network based on inefficiently marked packets, particularly where preempting only a certain number of flows would alleviate congestion while allowing a greater number of flows to maintain their connectivity and QoS levels.